OPENING QUESTIONS:
Naming your screen objects isn't just helpful when you share your code with your team members or helping others decipher your code if you can't be there to work on it in person.
Naming screen objects clearly, concisely and *INTERCHANGABLY* can be super helpful too.
For example naming two buttons that have similar actions:
- hideradiobtn
- showradiobtn
can have benefits that aren't always obvious initially.
What do you suppose those might be?
═══════════════════════════
COURSE DOCUMENT: Ver 1.64 is HERE
WORK O' THE DAY:
I've created a short video that outlines some not-so-obvious benefits of naming screen objects in app lab using simple, interchangeable terms.
I'll demo that in real time here and then let you refer to the video at your leisure (I'll do a bunch of those as we go and place then in the study guides section of the website.
Video is HERE
═══════════════════════════
There is a kind of frustrating (no doubt designed to be 'helpful' feature in APP Lab. Pretty much anything you do causes a new tab to open in your browser. If you aren't careful, you'll end up with multiple, multiple copies of versions of copies of versions of your code all loaded at once.
Don't do that.
Why?
Today we're going to play a bit more with drop down boxes since they can be such interesting, helpful but pesky beasts.
NAMING your program and getting rid of the pesky 'remix' label can be most helpful.
Simply adding 01, 02, 03 to the end of your program name is an excellent idea.
Notice that adding the leading zero can help with sorting program names later on. Using that approach you have between 0 and 99 program version names!
═══════════════════════════
Take a look at THIS basic start
Then we'll go to Step #2 to investigate the differences between different sorts of events such as 'click', 'change', 'keyup', 'mouseover' etc...
Step #3 - Work with your team to update the existing text box with the selection made by the users choosing an item from the drop-down box
My solution is HERE